1
2
Következő
Nem.
A JSON csak adat, és ha megjegyzést fűz hozzá, akkor az is adat lesz.
Lehet, hogy van egy kijelölt "_comment" (vagy valami más) neve, amelyet a JSON-adatokat használó alkalmazások figyelmen kívül hagynak.
Valószínűleg jobb lenne, ha a megjegyzés a JSON-t előállító / fogadó folyamatokban lenne, mivel állítólag előre tudják, hogy mi lesz a JSON adat, vagy legalábbis annak felépítése.
De ha úgy döntött, hogy:
{
"_comment": "ide kerül a megjegyzés szövege ...",
"szószedet": {
"title": "példa szószedet",
"GlossDiv": {
"title": "S",
"GlossList": {
"GlossEntry": {
"ID": "SGML",
"SortAs": "SGML",
"GlossTerm": "Normál általánosított nyelv"
"Betűszó": "SGML",
"Rövidítés": "ISO 8879: 1986",
"GlossDef": {
"para": "Metajelölő nyelv, olyan jelölőnyelvek létrehozására, mint a DocBook.",
"GlossSeeAlso": ["GML", "XML"]
},
"GlossSee": "jelölés"
}
}
}
}
}
|
Nem, a //… vagy / *… * / űrlap megjegyzései nem engedélyezettek a JSON-ban. Ez a válasz a következőkön alapul:
https://www.json.org
RFC 4627:
Az alkalmazás / json média típusa a JavaScript objektum jelöléshez (JSON)
RFC 8259 A JavaScript Object Notation (JSON) adatcsere-formátum (felülírja az RFC-k 4627, 7158, 7159)
|
Tartalmazza a megjegyzéseket, ha úgy dönt; elemzés vagy továbbítás előtt csíkokkal távolítsa el őket.
Most kiadtam a JSON.minify () fájlt, amely eltávolítja a megjegyzéseket és a szóközöket a JSON blokkjából, és érvényessé teszi a JSON elemzést. Tehát, használhatja, mint:
JSON.parse (JSON.minify (my_str));
Amikor kiadtam, hatalmas visszhangot kaptam, akik még az ötletével sem értenek egyet, ezért úgy döntöttem, hogy átfogó blogbejegyzést írok arról, hogy miért van értelme a kommenteknek a JSON-ban. Ez magában foglalja a JSON alkotójának ezt a figyelemre méltó megjegyzését:
Tegyük fel, hogy a JSON-ot használja a konfigurációs fájlok megőrzéséhez, amelyeket fel kíván jegyezni. Folytassa, és illessze be az összes tetsző megjegyzést. Ezután vezesse át a JSMin-en, mielőtt átadja a JSON-elemzőjének. - Douglas Crockford, 2012
Remélhetőleg ez hasznos azok számára, akik nem értenek egyet azzal, hogy a JSON.minify () miért lehet hasznos.
|
A JSON-ból a megjegyzéseket terv szerint eltávolították.
Eltávolítottam a JSON-tól a megjegyzéseket, mert láttam, hogy az emberek értelmezési irányelvek megfogalmazására használják őket, ami gyakorlatilag megsemmisítette az interoperabilitást. Tudom, hogy a megjegyzések hiánya néhány embert szomorúvá tesz, de nem szabad.
Tegyük fel, hogy a JSON-ot használja a konfigurációs fájlok megőrzéséhez, amelyeket fel kíván jegyezni. Folytassa, és illessze be az összes tetsző megjegyzést. Ezután vezesse át a JSMin-en, mielőtt átadja a JSON-elemzőjének.
Forrás: Douglas Crockford nyilvános nyilatkozata a G + -on
|
A JSON nem támogatja a megjegyzéseket. Azt sem tervezték, hogy konfigurációs fájlokhoz használják, ahol megjegyzésekre lenne szükség.
A Hjson egy konfigurációs fájlformátum az emberek számára. Nyugodt szintaxis, kevesebb hiba, több megjegyzés.
A JavaScript, Java, Python, PHP, Rust, Go, Ruby, C ++ és C # könyvtárakért lásd: hjson.github.io.
|
NYILATKOZAT: GARANCIÁJA érvénytelen
Mint rámutattak, ez a hack kihasználja a specifikáció megvalósítását. Nem minden JSON-elemző fogja érteni ezt a fajta JSON-t. Különösen a streaming parserek fojtogatnak.
Érdekes érdekesség, de egyáltalán nem szabad semmire használni. Az alábbiakban az eredeti válasz található.
Találtam egy kis feltörést, amely lehetővé teszi olyan megjegyzések elhelyezését egy JSON fájlban, amelyek nem befolyásolják az elemzést, vagy semmilyen módon nem változtatják meg az ábrázolt adatokat.
Úgy tűnik, hogy egy objektum literál deklarálásakor két értéket adhat meg ugyanazzal a kulccsal, és az utolsó előnyben részesítendő. Ha hiszed, ha nem, kiderül, hogy a JSON parserek ugyanúgy működnek. Tehát ezt felhasználhatjuk olyan megjegyzések létrehozására a JSON forrásban, amelyek nem lesznek jelen egy elemzett objektum reprezentációban.
({a: 1, a: 2});
// => Objektum {a: 2}
Object.keys (JSON.parse ('{"a": 1, "a": 2}')). Hossz;
// => 1
Ha ezt a technikát alkalmazzuk, akkor a megjegyzett JSON fájl a következőképpen nézhet ki:
{
"api_host": "Az API-kiszolgáló gazdagépneve. Megadhatja a portot is.",
"api_host": "hodorhodor.com",
"retry_interval": "A sikertelen API hívások újrapróbálkozása közötti másodpercek közötti intervallum",
"retry_interval": 10,
"auth_token": "A hitelesítési token. A fejlesztői irányítópulton elérhető a" Beállítások "részben,
"auth_token": "5ad0eb93697215bc0d48a7b69aa6fb8b",
"kedvenc_számok": "Minden idők kedvenc számaimat tartalmazó tömb",
"kedvenc_számok": [19, 13, 53]
}
A fenti kód érvényes JSON. Ha elemzi, egy ilyen objektumot kap:
{
"api_host": "hodorhodor.com",
"retry_interval": 10,
"auth_token": "5ad0eb93697215bc0d48a7b69aa6fb8b",
"kedvenc_számok": [19,13,53]
}
Ami azt jelenti, hogy a megjegyzéseknek nyoma sincs, és nem lesznek furcsa mellékhatásaik.
Boldog hackelést!
|
Fontolja meg a YAML használatát. Ez majdnem a JSON alcsoportja (gyakorlatilag az összes érvényes JSON érvényes YAML), és lehetővé teszi a megjegyzéseket.
|
Nem teheti. Legalábbis ez a tapasztalatom a json.org gyors pillantásával.
A JSON-nak megvan a szintaxisaazon az oldalon vizualizálták. Nincs megjegyzés a megjegyzésekről.
|
A megjegyzések nem hivatalos szabványok, bár néhány elemző támogatja a C ++ - stílusú megjegyzéseket. Az egyik a JsonCpp. A példákban van ez:
// Konfigurációs beállítások
{
// Alapértelmezett kódolás a szöveghez
"kódolás": "UTF-8",
// Indításkor betöltött plug-inek
"plug-inek": [
"piton",
"c ++",
"rubin"
],
// A tabulátor behúzásának mérete
"indent": {"length": 3, "use_space": true}
}
A jsonlint nem érvényesíti ezt. Tehát a megjegyzések elemzőspecifikus kiterjesztések és nem szabványosak.
Egy másik elemző a JSON5.
A JSON TOML alternatívája.
További alternatíva a jsonc.
Az nlohmann / json legújabb verziója opcionálisan támogatja az elemzéssel kapcsolatos megjegyzések figyelmen kívül hagyását.
|
Helyette JSON-sémát kell írni. A JSON-séma jelenleg egy javasolt internetes specifikáció-tervezet. A dokumentáció mellett a séma használható a JSON-adatok hitelesítésére is.
Példa:
{
"description": "Egy személy",
"type": "object",
"tulajdonságok":
{
"név":
{
"type": "string"
},
"kor":
{
"type": "integer",
"maximum": 125
}
}
}
Dokumentációt nyújthat be a description schema attribútum használatával.
|
Ha Jacksont használ JSON-elemzőként, akkor így engedélyezi a megjegyzések engedélyezését:
ObjectMapper mapper = új ObjectMapper (). Configure (Feature.ALLOW_COMMENTS, true);
Akkor ilyen megjegyzéseid lehetnek:
{
kulcs: "érték" // Megjegyzés
}
A # beállítással kezdődő megjegyzéseket is megadhatja a következő beállításával:
mapper.configure (Feature.ALLOW_YAML_COMMENTS, true);
De általában (amint azt korábban megválaszoltuk) a specifikáció nem teszi lehetővé a megjegyzéseket.
|
Ezt találtam a Google Firebase dokumentációjában, amely lehetővé teszi, hogy megjegyzéseket tegyen a JSON-ba:
{
"//": "Néhány böngésző ezt használja a push értesítések engedélyezésére.",
"//": "Minden projektnél ugyanaz, ez nem a projekt feladóazonosítója",
"gcm_sender_id": "1234567890"
}
|
NEM. A JSON korábban támogatta a megjegyzéseket, de visszaéltek velük és eltávolították a szabványból.
A JSON készítőjétől:
Eltávolítottam a JSON-tól a megjegyzéseket, mert láttam, hogy az emberek értelmezési irányelvek megfogalmazására használják őket, ami gyakorlatilag megsemmisítette az interoperabilitást. Tudom, hogy a megjegyzések hiánya néhány embert szomorúvá tesz, de nem szabad. - Douglas Crockford, 2012
A hivatalos JSON webhely a JSON.org oldalon található. A JSON-t az ECMA International szabványként határozta meg. A szabványok felülvizsgálatához mindig folyik egy petíciós eljárás. Nem valószínű, hogy a JSON szabványhoz több okból is hozzáadják a kommentárokat.
A JSON dizájnja az XML-hez könnyen fordítottan módosítható (emberi elemzett) alternatíva. Még annyiban is leegyszerűsítik, hogy a feljegyzések feleslegesek. Ez nem is jelölőnyelv. A cél a stabilitás és az interoperabilitás.
Bárki, aki megérti az objektumorientáció "van" kapcsolatát, megértheti a JSON bármely szerkezetét - ez az egész. Ez csak egy irányított aciklusos gráf (DAG) csomópontcímkékkel (kulcs / érték párok), amely szinte univerzális adatstruktúra.
Csak ez a szükséges megjegyzés lehet: "// Ezek DAG címkék". A kulcsnevek a lehető leginformatívabbak lehetnek, tetszőleges szemantikai aritást tesznek lehetővé.
Bármely platform csak néhány kódsorral elemezheti a JSON-t. Az XML olyan összetett OO könyvtárakat igényel, amelyek sok platformon nem életképesek.
A kommentárok csak a JSON-t teszik kevésbé interoperábilissá. Egyszerűen nincs más hozzáadható, hacsak nem igazán kell egy jelölőnyelv (XML), és nem érdekel, hogy a megmaradt adatok könnyen elemezhetők-e.
DE amint azt a JSON készítője is megfigyelte, a JS mindig is támogatta a megjegyzéseket:
Folytassa, és illessze be az összes tetsző megjegyzést.
Ezután vezesse át a JSMin-en, mielőtt átadja a JSON-elemzőjének. - Douglas Crockford, 2012
|
Ha a JSON karakterláncot tartalmazó szövegfájlt valamilyen program el fogja olvasni, mennyire nehéz lenne a C vagy a C ++ stílusú megjegyzéseket eltávolítani a használata előtt?
Válasz: Ez egy bélés lenne. Ha ezt megteszi, akkor a JSON fájlokat lehet használni konfigurációs fájlként.
|
Ha a Newtonsoft.Json könyvtárat használja az ASP.NET-lel olvasásra / dezerializálásra, használhatja a JSON-tartalomhoz tartozó megjegyzéseket:
// "név": "karakterlánc"
// "id": int
vagy
/* Ez egy
megjegyzés példa * /
PS: Az egysoros megjegyzéseket csak a Newtonsoft Json 6+ verziója támogatja.
Kiegészítő megjegyzés azok számára, akik nem tudnak gondolkodni a dobozból: A JSON formátumot használom az alapvető beállításokhoz egy általam készített ASP.NET webalkalmazásban. Elolvastam a fájlt, a Newtonsoft könyvtár segítségével átalakítottam a beállítások objektummá, és szükség esetén használom.
Inkább kommenteket írok az egyes beállításokról magában a JSON fájlban, és valóban nem érdekel a JSON formátum integritása, amennyiben az általam használt könyvtár rendben van.
Úgy gondolom, hogy ez egy „könnyebben használható / megérthető” módszer, mint egy különálló „settings.README” fájl létrehozása és a benne található beállítások elmagyarázása.
Ha problémája van az ilyen jellegű használatsal; bocs, a dzsinn kialszik a lámpából. Az emberek találnának más felhasználási módokatJSON formátumban, és nem tehet róla.
|
A JSON ötlete az, hogy egyszerű adatcserét biztosítson az alkalmazások között. Ezek általában webalapúak, a nyelv pedig JavaScript.
Nem igazán teszi lehetővé a megjegyzéseket, mint olyanokat, azonban a megjegyzés átadása az adatokban szereplő név / érték párok egyikeként minden bizonnyal működni fog, bár ezeket az adatokat nyilvánvalóan figyelmen kívül kell hagyni vagy kifejezetten az elemző kódnak kell kezelnie.
Mindez azt jelenti, hogy nem az a cél, hogy a JSON fájl tartalmazzon hagyományos értelemben vett megjegyzéseket. Csak az adatoknak kellene lenniük.
Nézze meg a JSON webhelyét további részletekért.
|
A JSON nem támogatja natívan a megjegyzéseket, de elkészítheti saját dekóderét vagy legalább előfeldolgozóját a megjegyzések eltávolításához, ez teljesen rendben van (mindaddig, amíg csak figyelmen kívül hagyja a megjegyzéseket, és nem arra használja őket, hogy irányítsa, hogyan dolgozza fel az alkalmazás a JSON-adatokat ).
JSON nem kapott megjegyzést. A JSON-kódoló NEM adhat ki kommenteket.
A JSON dekóder elfogadhatja és figyelmen kívül hagyhatja a megjegyzéseket.
A megjegyzéseket soha nem szabad értelmes továbbításra használni. Vagyis
mire való a JSON.
Vö .: Douglas Crockford, a JSON spec. Szerzője
|
Most találkoztam ezzel a konfigurációs fájloknál. Nem akarom használni az XML-t (részletes, grafikus, csúnya, nehezen olvasható), vagy az "ini" formátumot (nincs hierarchia, nincs igazi szabvány stb.), Vagy a Java "Properties" formátumot (például .ini).
A JSON mindent megtehet, amit tehet, de ez kevésbé bőbeszédű és emberileg olvashatóbb - és a parserek sok nyelven könnyűek és mindenütt jelen vannak. Ez csak egy adatfa. De a sávon kívüli megjegyzések gyakran szükségesek az "alapértelmezett" konfigurációk és hasonlók dokumentálásához. A konfigurációk soha nem lehetnek "teljes dokumentumok", hanem a mentett adatok fái, amelyek szükség esetén ember által is olvashatók.
Gondolom, az "érvényes" JSON-ra "#": "comment" használható.
|
Ez a JSON könyvtárától függ. A Json.NET támogatja a JavaScript-stílusú megjegyzéseket, / * commment * /.
Lásd még egy Stack Overflow kérdést.
|
A JSON-nak sok értelme van a konfigurációs fájlok és más helyi használat szempontjából, mivel mindenütt jelen van, és mivel sokkal egyszerűbb, mint az XML.
Ha az embereknek komoly okaik vannak arra, hogy észrevételeket tegyenek a JSON-ban az adatok (akár érvényesek, akár nem) közlésekor, akkor a JSON valószínűleg két részre osztható:
JSON-COM: JSON a vezetéken, vagy a JSON adatok közlésénél alkalmazandó szabályok.
JSON-DOC: JSON dokumentum, vagy JSON fájlokban vagy lokálisan. Érvényes JSON-dokumentumot meghatározó szabályok.
A JSON-DOC engedélyezi a megjegyzéseket, és más kisebb különbségek is előfordulhatnak, például a szóköz kezelése. A parserek könnyen konvertálhatnak egyik specifikációból a másikba.
Ami Douglas Crockford e kérdésben tett megjegyzését illeti (@Artur Czajka hivatkozva)
Tegyük fel, hogy a JSON-ot használja a konfigurációs fájlok megőrzéséhez, amelyeket fel kíván jegyezni. Folytassa, és illessze be az összes tetsző megjegyzést. Ezután vezesse át a JSMin-en, mielőtt átadja a JSON-elemzőjének.
Általános konfigurációs fájlokról beszélünk (több nyelven / platformon), és ő egy JS specifikus segédprogrammal válaszol!
Biztos, hogy a JSON-specifikus tömörítés bármilyen nyelven megvalósítható,
de ezt szabványosítsák, így mindenhol elérhetővé válik az összes nyelven és platformon működő parserek között, így az emberek abbahagyják az idejük pazarlását a funkció hiányában, mert megfelelő felhasználási lehetőségekkel rendelkeznek, keresik a kérdést az online fórumokon, és felhívják az embereket, hogy rossz ötlet vagy azt sugallja, hogy a megjegyzések szövegfájlokból történő egyszerű eltávolítása egyszerű.
A másik kérdés az interoperabilitás. Tegyük fel, hogy van egy könyvtárad vagy API-d, vagy bármilyen alrendszered, amelyhez társul néhány konfigurációs vagy adatfájl. És ez az alrendszer az
hogy különböző nyelveken érhető el. Akkor azt mondod az embereknek: mellesleg
ne felejtsd el kitörölni a JSON fájlok megjegyzéseit, mielőtt továbbadnád az elemzőhöz!
|
Ha a JSON5-et használja, megjegyzést fűzhet hozzá.
A JSON5 a JSON javasolt kiterjesztése, amelynek célja, hogy megkönnyítse az emberek számára a kézi írást és karbantartást. Ezt úgy teszi meg, hogy néhány minimális szintaxis funkciót közvetlenül az ECMAScript 5-ből ad hozzá.
|
A Dojo Toolkit JavaScript eszköztár (legalábbis az 1.4-es verziótól kezdve) lehetővé teszi megjegyzések felvételét a JSON-ba. A megjegyzések formátuma lehet / * * /. A Dojo Toolkit a Jojo-t a dojo.xhrGet () híváson keresztül fogyasztja.
Más JavaScript eszközkészletek is hasonlóan működhetnek.
Ez hasznos lehet, ha alternatív adatstruktúrákkal (vagy akár adatlistákkal) kísérletezünk, mielőtt kiválasztanánk a végső opciót.
|
A JSON nem keretezett protokoll. Ez egy nyelv nélküli formátum. Tehát a megjegyzés formátuma nincs meghatározva a JSON számára.
Ahogy sokan javasolták, vannak olyan trükkök, például duplikált kulcsok vagy egy speciális kulcs _megjegyzés, amelyet használhat. Tőled függ.
|
Megjegyzéseid lehetnek a JSONP-ban, de a tiszta JSON-ban nem. Éppen egy órát töltöttem azzal, hogy a Highcharts ezen példájával működhessek a programomban:
Ha követi a linket, látni fogja
? (/ * AAPLkorábbi OHLC adatok a Google Finance API-tól * /
[
/ * 2006. május * /
[1147651200000,67.79],
[1147737600000,64.98],
...
[1368057600000,456.77],
[1368144000000,452.97]
]);
Mivel a helyi mappámban volt hasonló fájl, nem voltak problémák az azonos eredetű házirenddel kapcsolatban, ezért úgy döntöttem, hogy tiszta JSON-t használok ... és természetesen a $ .getJSON a megjegyzések miatt némán bukott.
Végül csak egy kézi HTTP kérést küldtem a fenti címre, és rájöttem, hogy a tartalomtípus text / javascript volt, mivel a JSONP tiszta JavaScript-et ad vissza. Ebben az esetben megjegyzéseket megengedünk. De az alkalmazásom tartalom típusú alkalmazást / json adott vissza, ezért el kellett távolítanom a megjegyzéseket.
|
Ez egy "tudsz" kérdés. És itt van egy igen válasz.
Nem, nem használhat duplikált objektumtagokat az oldalsó csatorna adatainak JSON-kódolásba töltésére. (Lásd: "Az objektumon belüli neveknek egyedinek kell lenniük" az RFC-ben.)
Igen, beillesztheti a JSON körüli megjegyzéseket, amelyeket elemezhet.
De ha egy tetszőleges mellékcsatorna-adatok beillesztésére és kibontására van szüksége egy érvényes JSON-ba, itt van egy válasz. Kihasználjuk az adatok nem egyedi megjelenítését egy JSON-kódolásban. Ez megengedett * az RFC második szakaszában "a szóköz megengedett a hat szerkezeti karakter előtt vagy után".
* Az RFC csak azt állítja, hogy "a szóköz a hat szerkezeti karakter előtt vagy után engedélyezett", és nem említi kifejezetten a karakterláncokat, számokat, "hamis", "igaz" és "null" karaktereket. Ezt a kihagyást az MINDEN megvalósításnál figyelmen kívül hagyják.
Először kanonizálja JSON-ját azáltal, hogy kicsinyíti:
$ jsonMin = json_encode (json_decode ($ json));
Ezután kódolja a megjegyzését binárisan:
$ hex = kicsomagolás ('H *', $ megjegyzés);
$ commentBinary = alap_konvertálás ($ hex [1], 16, 2);
Ezután állítsa be a bináris fájlját:
$ steg = str_replace ('0', '', $ commentBinary);
$ steg = str_replace ('1', "\ t", $ steg);
Itt van a kimenet:
$ jsonWithComment = $ steg. $ jsonMin;
|
Jogi nyilatkozat: Ez butaság
Valójában van mód megjegyzések hozzáadására és a specifikációban való tartózkodásra (nincs szükség további elemzőre). Ez nem eredményez ember által olvasható megjegyzéseket semmiféle elemzés nélkül.
Visszaélhet a következőkkel:
Jelentéktelen szóköz engedélyezett bármely jelző előtt vagy után.
A szóköz az alábbi kódok közül egy vagy több bármelyik szekvenciája
pontok: karaktertáblázatok (U + 0009), sor előtolás (U + 000A), kocsi
visszatérés (U + 000D) és szóköz (U + 0020).
Hacky módon visszaélhet ezzel, hogy megjegyzést fűzzen hozzá. Például: kezdje és fejezze be a megjegyzését egy füllel. Kódolja a megjegyzést az base3-ba, és használja a többi szóköz karaktert az ábrázolásukhoz. Például.
010212 010202 011000 011000 011010 001012 010122 010121 011021 010202 001012 011022 010212 011020 010202 010202
(Helló alap három az ASCII-ben) De 0 helyett szóköz használjon 1-et a sor előtoláshoz és 2-höz a kocsi visszaadást.
Ezzel csak sok olvashatatlan szóköz marad (hacsak nem készítesz IDE plugint a menet közbeni kódoláshoz / dekódoláshoz).
Soha nem is próbáltam ezt, nyilvánvaló okokból, és neked sem szabad.
|
A JSON önmagában nem engedélyezi a megjegyzéseket. Az érvelés teljesen ostoba, mert maga a JSON is használható megjegyzések készítéséhez, amely teljes mértékben kiküszöböli az érvelést, és egyáltalán nem indokolja az elemző adatterületét teljesen ugyanazon eredmény és lehetséges problémák miatt, mint amilyenek: fájl megjegyzésekkel.
Ha megpróbálja megjegyzéseket beírni (például // vagy / * * / vagy # használatával), akkor néhány elemző nem fog sikerülni, mert
a JSON specifikáción belül. Tehát soha nem szabad ezt megtenni.
Itt például, ahol a képmanipulációs rendszerem elmentett képjegyzeteket és néhány alapvető formázott (megjegyzés) információt (alul):
{
"Jelzések": [
{
"anchorX": 333,
"horgony": 265,
"areaMode": "Ellipszis",
"mértékbenX": 356,
"mértékbenY": 294,
"átlátszatlanság": 0,5,
"text": "Elliptikus terület a tetején",
"textX": 333,
"textY": 265,
"title": "1. jelölés"
},
{
"anchorX": 87,
"horgony": 385,
"areaMode": "Téglalap",
"mértékbenX": 109,
"mértékbenY": 412,
"átlátszatlanság": 0,5,
"text": "Rect area \ non bottom",
"textX": 98,
"textY": 385,
"title": "2. jelölés"
},
{
"anchorX": 69,
"horgony": 104,
"areaMode": "Sokszög",
"mértékbenX": 102,
"mértékbenY": 136,
"átlátszatlanság": 0,5,
"pointList": [
{
"i": 0,
"x": 83,
"y": 104
},
{
"i": 1,
"x": 69,
"y": 136
},
{
"i": 2,
"x": 102,
"y": 132
},
{
"i": 3,
"x": 83,
"y": 104
}
],
"text": "Egyszerű sokszög",
"textX": 85,
"textY": 104,
"title": "3. jelölés"
}
],
"imageXW": 512,
"imageYW": 512,
"imageName": "lena_std.ato",
"tinyDocs": {
"c01": "JSON kép jelölési adatai:",
"c02": "-------------------------",
"c03": "",
"c04": "Ezek az adatok képmegjelöléseket és kapcsolódó területeket tartalmaznak",
"c05": "kiválasztási információ, amely eszközt biztosít egy",
"c06": "képgaléria elliptikus jelölések megjelenítéséhez,",
"c07": "téglalap, sokszög vagy szabadkézi terület jelzése",
"c08": "a galéria látogatójának megjelenített kép felett.",
"c09": "",
"c10": "Az X és Y pozíciók mind a képen vannaktér. A kép",
"c11": "a felbontást imageXW és imageYW formátumban adjuk meg, amely",
"c12": "a jelölési területeket méretükre méretezed",
"c13": "helyek és méretek a kép megjelenítéséhez",
"c14": "méretaránytól függetlenül.",
"c15": "",
"c16": "Az ellipsziseknél a horgony az ellipszis közepe,",
"c17": "és a mértéke az X, illetve az Y sugár.",
"c18": "",
"c19": "A téglalapok esetében a horgony a bal felső és a",
"c20": "a terjedelmek a jobb alsó sarokban vannak.",
"c21": "",
"c22": "Szabadkézi és sokszög módok esetén a pointList",
A "c23": "számozott XY pontokat tartalmaz. Ha a terület",
"c24": "zárva van, az utolsó pont megegyezik a",
"c25": "először, tehát csak a rajzolással kell foglalkoznia",
"c26": "vonalak a lista pontjai között. Horgony és kiterjedés",
"c27": "a jelzett bal felső és jobb alsó részén vannak beállítva",
"c28": "régió, és egyszerűsített téglalapként használható",
"c29": "észlelni az egérmutatót az ilyen típusok felett"
"c30": "területek.",
"c31": "",
"c32": "A textx és texty pozíciók biztosítják az alapvető pozicionálást",
"c33": "információ a szöveges információk megkereséséhez",
"c34": "a területhez tartozó ésszerű helyen",
"c35": "jelzés".,
"c36": "",
"c37": "Az átlátszatlanság 0 és 1 közötti érték, ahol .5 jelentése",
"c38": "50% -os átlátszatlan háttér és 1.0 teljesen átlátszatlan"
"c39": "háttér. Az ajánlás a régiók rajzolása",
"c40": "csak akkor, ha a felhasználó a kép fölé viszi a mutatót,",
"c41": "és hogy a régiókhoz társított szöveg rajzolandó",
"c42": "csak akkor, ha a felhasználó a mutatót a jelzett fölé viszi",
"c43": "régió".
}
}
|
Projektünkhöz strip-json-commenteket használunk. Valami ilyesmit támogat:
/ *
* Leírás
* /
{
// szivárványok
"egyszarvú": / * ❤ * / "torta"
}
Egyszerűen npm install --save strip-json-comments telepítéséhez és használatához, például:
var strip_json_comments = igényel ('strip-json-comments')
var json = '{/ * szivárvány * / "egyszarvú": "torta"}';
JSON.parse (strip_json_comments (json));
// => {egyszarvú: 'torta'}
|
Esetemben a megjegyzéseket hibakeresési célokra kell használnom, közvetlenül a JSON-struktúra kimenete előtt. Ezért úgy döntöttem, hogy a hibakeresési információkat használom a HTTP fejlécben, hogy elkerüljük az ügyfél feltörését:
header ("My-Json-Comment: Igen, tudom, hogy ez egy megoldás ;-)");
|
Ha egy JSON-elemet részekre akarok vágni, hozzáadom a "dummy comment" sorokat:
{
"#############################" : "1. rész",
"data1": "value1",
"data2": "value2",
"#############################" : "2. rész",
"data4": "value3",
"data3": "value4"
}
|
1
2
Következő
Nagyon aktív kérdés. Nyerjen 10 hírnevet a kérdés megválaszolásához. A jó hírnév követelménye megvédi ezt a kérdést a spamektől és a nem válaszolóktól.
Nem a keresett válasz? Böngésszen a Json megjegyzéssel címkézett egyéb kérdésekben, vagy tegye fel saját kérdését.